1. Field of the Invention The present invention relates to a technique of compiling a source program.
2. Description of the Related Art
In a dynamic programming language such as JavaScript (registered trademark), codes are rewritten by using a method so-called type inference for acceleration. For example, a method so-called Inline Cache is implemented in order to shorten time to access a property of an object (see Patent Document 1 or the like, for example).
In the Inline Cache, an access code to access a property is dynamically generated at a first access time based on hidden type data (Hidden Type) at back. Then, the generated access code is called at an access after a second time, when it is confirmed that the hidden type data is the same as that of the previous access. When a property is newly added, new hidden type data is generated and is set as hidden type data of an object.
For example, when “Point(x, y)” is newly executed in the following function of JavaScript
function Point (x, y) {this.x=x; this.y=y;},
values of property x, y are written in a memory area corresponding to an offset indicated by hidden type data. By executing a code dynamically generated based on the hidden type data, an access to the property is performed.
The above described method is effective for an interpreter in which a code is generated when executing, however, cannot be applied to a compiler in which an object code is previously generated from a source code. It means that as the compiler is originally static, type inference introduced by a dynamic programming language does not suit the compiler.
Thus, in a compiler, there are many cases that a hash table is used when actualizing a high-speed access to a property of an object. In the hash table, a table is structured using an index value and a value.
FIG. 1A to FIG. 3B illustrate a relationship between an object and a hash table generated in a process of compiling    obj={ };    obj.x =123;    obj.y =456;
as a source code.
By executing a first line “obj={ };” of the source code as illustrated in FIG. 1A, an object “obj” is generated as illustrated in FIG. 1B. At this time, a hash table is not generated yet and, a pointer “entries” to the hash table is “null” and the number of components of the property “occupied” is “0” in the object “obj”.
By executing a second line “obj.x=123;” of the source code as illustrated in FIG. 2A, the hash table is generated and the pointer “entries” in the object “obj” indicates the hash table. Further, a pointer to a character string “x” (default is null) is set at an alignment component, among alignment components of the hash table, corresponding to a value of a remainder (mod) when dividing a hashed value of the character string “x” of a property “x” by the number of components of the hash table, and “123” is set as its value as illustrated in 2B. The number of components “occupied” in the object “obj” is set as “1”.
By executing a third line “obj.y=456;” of the source code as illustrated in FIG. 3A, a pointer to a character string “y” is set at an alignment component, among the alignment components of the hash table, corresponding to a value of a remainder when dividing a hashed value of the character string “y” of the property “y” by the number of components of the hash table, and “456” is set as its value as illustrated in FIG. 3B. The number of components “occupied” in the object “obj” is set as “2”.
A code to access the property by referring to the hash table is embedded in a compiled object code.
As described above, in a static compiler, it was necessary to use a hash table in order to actualize a high-speed access to a property when executing a compiled object code, and there was a limitation in actualizing acceleration. It means that when the hash table is used, as time is required for a matching process for generating index values or searching the hash table, a sufficient acceleration cannot be actualized.